एंटरप्राइज़ एप्लिकेशन डेवलपमेंट में टीडीडी को प्रभावी ढंग से कैसे लागू करें

मुझे एक नया एंटरप्राइज़ एप्लिकेशन बनाने वाली कंपनी में काम करना शुरू किए छह महीने हो चुके हैं। मेरी नई टीम जोड़ी प्रोग्रामिंग और टेस्ट-ड्रिवेन डेवलपमेंट (टीडीडी) जैसी कुछ चुस्त प्रथाओं का पालन करती है, और मुझे ईमानदारी से लगता है कि सूरज हमारे लिए चमक रहा है!

हां तकरीबन।

कुछ ऐसे मुद्दे हैं जिनका मैं अब और पिछले औद्योगिक अनुभवों में ठोस उद्यम अनुप्रयोगों के निर्माण के विषय पर सामना कर रहा हूं, जिन्हें मैं इस लेख में आपको समझाना चाहता हूं।

इसके अलावा, मैं एंटरप्राइज़ एप्लिकेशन बनाने के लिए एक सरल परीक्षण-प्रथम-आधारित पद्धति का भी प्रस्ताव दूंगा जो टीम संचार को बढ़ाता है और तेजी से उच्च गुणवत्ता वाले कोड वितरण को बढ़ावा देता है।

आगे की हलचल के बिना, आइए इसे प्राप्त करें!

टीडीडी की रोशनी और छाया

सॉफ्टवेयर के तेजी से प्रोटोटाइप के लिए फुर्तीली प्रथाएं अत्यधिक फायदेमंद हैं। TDD ऐसी प्रथाओं के मूल में बैठता है, जो एक सर्वोपरि संपत्ति के साथ सॉफ्टवेयर प्रदान करता है: मजबूती। परीक्षण लिखना डेवलपर्स को उनके द्वारा बनाए गए सॉफ़्टवेयर घटकों के अपेक्षित और असाधारण व्यवहार के बारे में सोचने, कोड गुणवत्ता बढ़ाने और कार्यात्मक आवश्यकताओं की पूर्ति सुनिश्चित करने के लिए मजबूर करता है।

इसके अलावा, टीडीडी एक शक्तिशाली अभ्यास है जो डेवलपर्स को अपने कोड को कार्यात्मक आवश्यकता अपडेट के लिए ठीक करने, साफ करने और अनुकूलित करने से डरने में सक्षम बनाता है । और वह सब बढ़िया है। हालांकि, टीडीडी को अभ्यास में लाना इतना आसान नहीं है।

किसी भी नए उद्यम अनुप्रयोग के निर्माण की शुरुआत में, हम (डेवलपर्स) कई कार्यात्मक आवश्यकताओं को इकट्ठा करते हैं। फिर, हम उपयोग के मामलों का एक सेट प्राप्त करते हैं जो ऐसी कार्यात्मक आवश्यकताओं को पूरा करेगा। उसके बाद, हम अलग-अलग परतों पर बैठे सॉफ्टवेयर घटकों को विकसित करते हैं, उच्चतम से निम्नतम तक, एप्लिकेशन के दिल तक, यानी इसके डोमेन मॉडल को ड्रिल करते हुए। यह टॉप-डाउन सॉफ़्टवेयर डेवलपमेंट प्रक्रिया की परिभाषा है।

हालांकि, बॉटम-अप सॉफ्टवेयर डेवलपमेंट प्रोसेस टीडीडी के साथ बेहतर तरीके से फिट बैठता है। टॉप-डाउन विकल्प की तुलना में, बॉटम-अप एक अधिक व्यावहारिक दृष्टिकोण है, क्योंकि यह हमें, डेवलपर्स को, सबसे बुनियादी (यानी, डोमेन मॉडल) से शुरू होने वाले अप्रत्यक्ष रूप से सभी स्तरों को कवर करने और धीरे-धीरे उच्च परतों की ओर बढ़ने में सक्षम बनाता है। अमूर्त यह ध्वनि एप्लिकेशन कोड नींव के उत्पादन की अनुमति देता है, जो बदले में हमें अपने काम में बहुत विश्वास दिलाता है। टीडीडी को टॉप-डाउन दृष्टिकोण में लागू करने के लिए, हालांकि, पहले उच्च परतों पर स्थित सॉफ़्टवेयर घटकों के लिए परीक्षण लिखना चाहिए। इस तरह, डेवलपर्स को किसी भी निचली परत के घटकों पर निर्भरता का मजाक उड़ाने की आवश्यकता नहीं है, क्योंकि वे अभी तक मौजूद नहीं हैं।

इस तरह की निर्भरताएँ बनाने की आवश्यकता पहले से ही एक समस्या है क्योंकि निचली परत के घटकों का मज़ाक उड़ाना हमेशा संभव नहीं होता है या, सर्वोत्तम स्थिति में, प्रति-सहज लगता है जैसे, कल्पना करें कि किसी डोमेन ऑब्जेक्ट के तर्क का मज़ाक उड़ाया जाए सेवा घटक परीक्षण।

इसके अलावा, मुझे व्यक्तिगत रूप से संदेह है कि यह किसी भी मूल्य को लाएगा, क्योंकि मुझे लगता है कि मध्यवर्ती घटक सत्यापन हमेशा बाहरी सेवाओं (उदाहरण के लिए, डेटाबेस) को छोड़कर सभी निर्भरताओं का प्रयोग करना चाहिए, जिसका मजाक उड़ाया जा सकता है। इससे भी महत्वपूर्ण बात यह है कि कोड के रूप में गैर-तुच्छ कार्यात्मक आवश्यकताओं को महसूस करने के लिए अंतर्निहित जटिलता के कारण, कोई तकनीकी प्रभाव को पूरी तरह से नहीं समझता है कि कुछ दी गई कार्यात्मक आवश्यकताएं डोमेन मॉडल पर होती हैं जब तक कि कोई डोमेन मॉडल के कार्यान्वयन के दौरान उनके बारे में तर्क करना शुरू नहीं करता है।

एक बार फिर, इंटरमीडिएट सॉफ़्टवेयर घटकों के परीक्षण लिखना शुरू करने से अधिक मूल्य नहीं आता है, क्योंकि निचली परत सॉफ़्टवेयर कलाकृतियों के वास्तव में लागू होने के बाद उनमें से कई परीक्षण (यदि सभी नहीं) कूड़ेदान में फेंक दिए जाने की संभावना है।

इसके अलावा, मैंने सॉफ्टवेयर डेवलपर्स (विशेष रूप से जूनियर टीम के साथी) को किसी भी सत्यापन तर्क को लिखे बिना उपयोग के मामले के लिए अवधारणा के कुछ सबूतों को छोड़ और कार्यान्वित करते देखा है। यह कोड-प्रथम अभ्यास का उपयोग कर रहा है, जो टीडीडी के उद्देश्य को हरा देता है। इसके अलावा, उचित सतत वितरण प्रथाओं का पालन किए बिना, हमारे संस्करण नियंत्रण भंडार में गैर-सत्यापित कोड को समाप्त करने का एक उच्च जोखिम है।

तो, हम कार्यात्मक आवश्यकताओं के एक सेट को देखते हुए उद्यम अनुप्रयोगों के उत्पादन में टीडीडी को प्रभावी ढंग से कैसे लागू कर सकते हैं?

बचाव के लिए हेक्सागोनल वास्तुकला

इंटरनेट पर हेक्सागोनल आर्किटेक्चर पर बहुत सारा साहित्य है। मैं विशेष रूप से एलिस्टेयर कॉकबर्न द्वारा लिखित विषय पर श्वेत पत्र पढ़ने की सलाह दूंगा।

वर्तमान लेख के उद्देश्य के लिए, कृपया मुझे आपको एक वास्तविक जीवन की लघु कहानी बताने की अनुमति दें, जिसका उद्देश्य हेक्सागोनल आर्किटेक्चर की प्रेरणा और मुख्य लाभों को संक्षेप में बताना है: कई वर्षों में जब मैं उद्यम अनुप्रयोगों को विकसित कर रहा हूं, मैंने कई लोगों को देखा है ( खुद को शामिल किया) हमारे वास्तविक मिशन के बजाय अन्य विषयों पर ध्यान केंद्रित करने वाली नई परियोजनाएं शुरू करना। इस तरह के मिशन में उन कंपनियों को वास्तविक मूल्य प्रदान करना शामिल है जिनके लिए हम काम करते हैं। वह मान हमारे अनुप्रयोगों के डोमेन तर्क पर है।

अपनी पुस्तक क्लीन आर्किटेक्चर में अंकल बॉब को पैराफ्रेशिंग करते हुए, बाकी सब कुछ एक व्याकुलता है, एक कार्यान्वयन विवरण जिसे आदर्श रूप से विकास के अंत तक स्थगित किया जा सकता है (और होना चाहिए)। कार्यान्वयन विवरण के उदाहरण डेटाबेस प्रौद्योगिकियां, नियंत्रक तर्क, या दृश्यपटल प्रौद्योगिकी हैं। यहां तक कि बैकएंड फ्रेमवर्क एक कार्यान्वयन विवरण है जिसे हम बाद में विकास प्रक्रिया में चुन सकते हैं यदि हम वास्तव में चाहते हैं। हेक्सागोनल आर्किटेक्चर, जिसे पोर्ट्स और एडेप्टर भी कहा जाता है, एक आर्किटेक्चरल पैटर्न है जिसका उद्देश्य बाहरी कार्यान्वयन विवरण से सॉफ़्टवेयर एप्लिकेशन कोर लॉजिक को अलग करना है।

हम डेवलपर्स को उद्यम अनुप्रयोगों के मूल तर्क पर ध्यान केंद्रित करना चाहिए और बाहरी सेवाओं के साथ संवाद करने के लिए आवश्यक तर्क के कार्यान्वयन को स्थगित करना चाहिए। उस लक्ष्य को प्राप्त करने के लिए, हमें वास्तव में कुछ इंटरफेस (तथाकथित पोर्ट ) लिखने और उन घटकों (तथाकथित एडेप्टर ) का मजाक उड़ाने की ज़रूरत है जो वास्तव में बाहरी सेवाओं के साथ संवाद करते हैं। इस प्रकार, एडेप्टर कार्यान्वयन बाद में विकास प्रक्रिया में आ सकता है। और बाद में वे आते हैं, बेहतर है, क्योंकि जब हम मुख्य तर्क का उत्पादन करते हैं तो हमें प्राप्त होने वाली सभी अंतर्दृष्टि वास्तव में उपयोगी साबित होती है कि कौन सी प्रौद्योगिकियों को चुनना है।

निम्नलिखित चित्र हेक्सागोनल वास्तुकला के कई मौजूदा चित्रों में से एक है:

उन तत्वों पर विचार करें जो आंतरिक षट्भुज की रचना करते हैं। डोमेन मॉडल के अलावा, एप्लिकेशन सेवाओं की एक परत भी है। ये सॉफ़्टवेयर घटक कोई डोमेन तर्क निर्दिष्ट नहीं करते हैं। इसके बजाय, वे एडेप्टर और डोमेन मॉडल लॉजिक के सरल समन्वयक हैं। एक एप्लिकेशन सेवा एक उपयोग के मामले का एहसास करती है जो एंटरप्राइज़ एप्लिकेशन के लिए कार्यात्मक आवश्यकताओं के सबसेट का ख्याल रखती है। आगे क्या होता है इसके लिए ध्यान में रखने के लिए यह महत्वपूर्ण डेटा है।

हेक्सागोनल आर्किटेक्चर-आधारित एंटरप्राइज़ एप्लिकेशन में टीडीडी का प्रभावी ढंग से उपयोग कैसे करें

जैसा कि मैंने पहले कहा था, बॉटम-अप सॉफ्टवेयर विकास प्रक्रिया का पालन करते समय टीडीडी लागू करना आसान होता है। हालांकि, हम में से कई लोगों को टॉप-डाउन दृष्टिकोण के बाद सिस्टम डिज़ाइन के बारे में तर्क करना आसान लगता है। और यद्यपि ऐसा लगता है कि हम हितों के टकराव का सामना कर रहे हैं, यह ठीक है क्योंकि हम उनके लिए कोड की एक भी पंक्ति लिखे बिना अपनी एप्लिकेशन सेवाओं को टॉप-डाउन डिजाइन करना शुरू कर सकते हैं (यानी, स्यूडोकोड या कुछ यूएमएल आरेख में स्केचिंग); जब तक हम डोमेन मॉडल के कार्यान्वयन को पूरा नहीं कर लेते।

कोडिंग शुरू करने से पहले, हम एप्लिकेशन सेवाओं की व्याख्या कुछ सॉफ़्टवेयर डिज़ाइन दिशानिर्देशों के रूप में कर सकते हैं जो हमारे द्वारा बनाए जाने वाले एंटरप्राइज़ एप्लिकेशन के लंबवत स्लाइस को निष्पादित करने के लिए हैं। प्रत्येक लंबवत टुकड़ा एक अपस्ट्रीम बाहरी सेवा या यूआई में उपयोगकर्ता द्वारा डाउनस्ट्रीम बाहरी सेवा पर निष्पादित किसी भी ऑपरेशन के लिए की गई कार्रवाई से उपयोग के मामले के पूरे निष्पादन पथ का प्रतिनिधित्व करता है। जब तक हम किसी एप्लिकेशन सेवा के डिज़ाइन के साथ समाप्त करते हैं, तब तक हमने पहचान लिया है कि हमें कौन से एडेप्टर और डोमेन घटकों को लागू करने की आवश्यकता है। अब जब हमारे पास डोमेन मॉडल पर दृश्यता है, तो हम टीडीडी को लागू करके इसके मूलभूत घटकों को लागू कर सकते हैं।

फिर, हम परीक्षण-प्रथम दृष्टिकोण के बाद एप्लिकेशन सेवा को लागू कर सकते हैं, किसी भी बाहरी सेवा एडेप्टर के लिए एक पोर्ट बना सकते हैं और इसके वास्तविक कार्यान्वयन का मज़ाक उड़ा सकते हैं। जब तक हम एप्लिकेशन सेवा और संबंधित डोमेन मॉडल के कार्यान्वयन के साथ काम करते हैं, हम यह पता लगा सकते हैं कि ऐसा कार्यान्वयन वैध है, बग-मुक्त और इसकी कार्यात्मक आवश्यकताओं से मेल खाता है। अंत में, हम एडेप्टर लॉजिक को लागू कर सकते हैं, साथ ही टीडीडी भी लागू कर सकते हैं।

यह कार्यप्रणाली उद्यम अनुप्रयोगों के तेजी से और क्रमिक कार्यान्वयन को सक्षम बनाती है, जिससे डेवलपर्स को उन सभी घटकों की वैधता में विश्वास हासिल करने की अनुमति मिलती है जो वे बिना किसी परीक्षण को फेंके बनाते हैं। इसके अलावा, यह कार्यात्मक आवश्यकता अद्यतनों पर कोई प्रतिबंध नहीं लगाता है।

निम्नलिखित प्रवाह आरेख एक उपयोग के मामले के तर्क को लिखने की कार्यप्रणाली को दर्शाता है। ध्यान दें कि मैं विशिष्ट परीक्षण प्रकारों के बारे में बात नहीं करता क्योंकि यह एक बहुत ही विवादास्पद विषय है, हालांकि मैं द प्रैक्टिकल टेस्ट पिरामिड लेख में उपयोग की जाने वाली परंपराओं और शब्दावली का पालन करने की सलाह दूंगा।

प्रस्तावित कार्यप्रणाली टीम कार्य वितरण को सरल बनाती है, चाहे वे अकेले या जोड़ियों में काम करें। इसके कुछ कदम समानांतर में किए जा सकते हैं, उदाहरण के लिए, एक टीम का साथी/जोड़ी बाहरी निर्भरता के किसी भी संदर्भ का मज़ाक उड़ाते हुए मूल तर्क का निर्माण कर सकता है, जबकि दूसरा ऐसी बाहरी निर्भरता के साथ एकीकरण कोड के विकास पर काम कर सकता है, क्योंकि ये दो भाग हैं decoupled, इस प्रकार प्रसव के समय को छोटा करता है। उन्हें केवल एक बंदरगाह के रूप में महसूस की गई बाहरी निर्भरता के लिए कुछ एपीआई बताने की जरूरत है। नकली और वास्तविक बाहरी निर्भरता दोनों को उपरोक्त पोर्ट इंटरफ़ेस को लागू करने की आवश्यकता है। इसी तरह, एक अन्य टीम/टीम के साथी/जोड़ी उपयोग के मामले के लिए फ्रंटएंड भाग को लागू कर सकती है, यदि वह उद्यम आवेदन की मांग है।

दूसरी ओर, इसकी संरचित प्रकृति के कारण, साथियों के बीच एक ठोस उपयोग के मामले के विकास की स्थिति को संप्रेषित करना आसान है। उपयोग के मामले के विकास को सौंपते समय, प्रस्थान करने वाली इकाई केवल नए को वर्तमान एप्लिकेशन सेवा के लिए इंगित कर सकती है जिसे वे डिजाइन या कार्यान्वित कर रहे थे। नई इकाई तब कोड बेस में एडेप्टर या डोमेन लॉजिक पर पहले से बनाई गई किसी भी चीज़ का पता लगा सकती है।

कार्यान्वयन विवरण पर एक अंतिम नोट: हम उन विवरणों में से कुछ को निर्दिष्ट करने के लिए अपने डोमेन मॉडल को अपडेट कर सकते हैं, डेटाबेस प्रौद्योगिकी के एनोटेशन / डेकोरेटर और अंतर्निहित ढांचे से इनपुट डेटा सत्यापन संसाधनों को लिखकर जो हमारे आवेदन की प्रकृति के लिए सबसे अच्छा समायोजित करता है। हालांकि मैं इसके खिलाफ सलाह दूंगा, क्योंकि यह हमारे डोमेन मॉडल में कार्यान्वयन विवरण लीक करेगा, जो कार्यान्वयन विवरण के बाद से सबसे अच्छा अभ्यास नहीं है और डोमेन मॉडल विभिन्न कारणों और आवृत्ति के लिए बदल जाता है। दूसरी ओर, जैसा कि वॉन वर्नोन ने अपनी पुस्तक इम्प्लीमेंटिंग डोमेन ड्रिवेन डिज़ाइन (डीडीडी) में समझाया है, हेक्सागोनल आर्किटेक्चर डीडीडी से निकटता से संबंधित है। हालांकि, आपको हेक्सागोनल आर्किटेक्चर पर आधारित जटिल उद्यम अनुप्रयोगों के निर्माण के लिए डीडीडी प्रथाओं और पैटर्न के सेट का पालन करने की आवश्यकता नहीं है, हालांकि मैं आपको अत्यधिक अनुशंसा करता हूं। लेकिन आखिरकार, वे निर्णय पूरी तरह आप पर निर्भर हैं।

निष्कर्ष

मजबूत उद्यम अनुप्रयोगों के निर्माण में परीक्षण-संचालित विकास एक शक्तिशाली अभ्यास है। टीडीडी को बॉटम-अप सॉफ्टवेयर डेवलपमेंट प्रक्रिया के बाद सबसे अच्छा लागू किया जाता है। हालाँकि, क्योंकि डेवलपर्स का उपयोग टॉप-डाउन दृष्टिकोण के बाद ऐसे अनुप्रयोगों के बारे में तर्क करने के लिए किया जाता है, इसे व्यवहार में लागू करना चुनौतीपूर्ण है। यह आलेख एंटरप्राइज़ अनुप्रयोगों के विकास में डेवलपर्स को प्रभावी ढंग से टीडीडी लागू करने में मदद करने के लिए एक सरल पद्धति का खुलासा करता है।